This article shares my understanding of automotive industry processes, quality, systematic efficiency, and tools. It also explains how my work at NIO and SAIC Zero-Base inspired the founding of MappingSpace, and its design philosophy—not just as an automotive R&D management tool, but as an extension of how engineers think.

Joining NIO: Why Are Software Problems Still Unsolved?

After my master's degree, I joined NIO as a quality engineer. I was on the factory final assembly line's last station: evaluating vehicle quality from a user perspective. In the first half of 2018, during the final sprint to production, we randomly picked 1-2 cars per week for a complete user-experience review. Exterior and interior issues were gradually converging, but software still had many problems.

I was responsible for vehicle software function review. I was excited at first—I was theoretically the first "user" to experience China's first truly mass-produced premium smart EV. But a year of quality testing poured cold water on me: as production neared, exterior and interior issues diminished, but software problems weren't fully resolved.

I had an opportunity to demo vehicle features to the smart cockpit test director. He sat in the ES8's backseat and watched me walk through vehicle functions—even features not yet developed. He was amazed that a factory QA engineer knew vehicle software so thoroughly. Through this, I transferred to the smart cockpit testing department.

Smart Cockpit: Deliver on Time or Ensure Quality?

At the smart cockpit test team, my first task was standardizing the team's process. The test team had no systematically recorded test cases—testing was entirely based on individual engineers' experience, and results varied greatly between testers.

So I pushed for written, structured test cases. We faced resistance: testers were swamped with rapid releases and had no time to write cases. After a few rounds of discussion, we agreed on a 3-step approach: outline test cases first, review them, then gradually fill in details.

As test cases started being written, I noticed something: testers loved using mind maps to write test cases. Not only was their thinking clear while writing, but reviewers could quickly spot missing scenarios compared to Word/Excel.

But because test cases were still offline (mind maps or Excel), product and developers saw outdated versions—causing inconsistency between requirements and test cases.

After outlining, testers didn't execute from the mind map directly—they converted it into an Excel, row by row. That's duplicative work.

Why not store all test case info directly in the mind map? Why not generate test execution reports directly from it? That question became MappingSpace's original creative spark.

Software Quality: Is ASPICE a Lifesaver?

NIO spent heavily to move fast in its early years, but rapid expansion left behind issues: R&D processes weren't stable, yet forward engineering opened up N fronts. R&D tools were fragmented—each department couldn't even integrate its own tools internally, let alone company-wide.

Through an internal training, I learned about ASPICE. After studying it for 1-2 weeks, I found its concepts aligned with my quality education background—I saw a solution. I proposed adopting ASPICE to my leader, but he had doubts: the team came from phone/internet backgrounds, ASPICE was unfamiliar, and how could we build detailed traceable documentation in a delivery-crunch atmosphere?

Later, I tried building ASPICE-style documentation and traceability in Jira. But the process change was too drastic for the team—the proposal died before it was even presented.

SAIC Zero-Base: The Tool Test Ground

Half a year after SAIC Zero-Base was founded, I joined its basic software team as a software quality engineer. I thought ASPICE was the key to automotive software quality.

The biggest problem: implementing ASPICE was hard with existing tools. We used Siemens Polarion (inherited from SAIC), but the smart cockpit team used Jira—so we needed data syncing between Polarion and Jira. Another department used TAPD. Three departments each built their own CI/CD around their own tool.

Why couldn't they use one tool company-wide? It wasn't that they didn't want to—it's that no such tool existed on the market. Jira+Confluence is Agile's gold standard, but adapting it for automotive ASPICE has no off-the-shelf solution. Polarion supports ASPICE, but its UI and usability drive engineers away.

Leaving to Start a Company: Tools That Extend How Humans Think

Could I build a tool that:

Supports Agile efficiency while satisfying ASPICE without extra work?

Unifies requirements, development, and testing—not switching between tools?

Has a learning curve of 5 minutes to master core logic?

"Mind maps are tools that spark creativity and innovation."

If mind maps could store multi-dimensional data, they wouldn't just support itemized tasks—they'd support writing complex engineering documents. So we added pop-up panels to mind maps, supporting all data types.

Product engineers write requirements in mind maps—thinking flows naturally. Architects write design docs in mind maps—everyone sees the architecture logic clearly. Testers write test cases in mind maps—reviewers enjoy playing with the visual layout.

According to internal data: requirements/architecture drafting time saved 50%, review time saved 40%, overall testing efficiency improved 60%.